Interaction between the JAM server and client operates by exchanging text-based messages, with each new line sent representing a new message. Choosing a text-based protocol allows each message to be human readable, allowing for simpler debugging and testing. Each message is split into a number of components, separated by a colon, as shown in the following example. Following these components should be a next-line character to signal that the message has ended.

\begin{alltt}
<KEYWORD>:<TRANSACTION ID>:<ARGUMENT 1>:
<ARGUMENT 2>:...:<ARGUMENT N>
\end{alltt}

\begin{itemize}
\item \textbf{Keyword} This component identifies the particular type of message. Each different type of message has its own unique keyword. These keywords follow a particular convention that will be discussed later on in section 4.2.

\item \textbf{Transaction ID} This component identifies a particular pair of messages. As a number of messages expect responses, a response to those messages must have a matching transaction ID. This means that if a number of requests are sent at the same time, they can be answered in any order as long as the transaction ID matches. This number should start from zero and increment with each pair of sent and received messages, per client. Should this number reach the maximum that can be stored as an \textit{int} in Java, it will wrap around to 0. This is based on the assumption that the volume of messages will be low enough for it not to be an issue that transaction IDs are reused in this way.

\item \textbf{Arguments} Following the keyword and transaction ID are a number of arguments. The exact number of arguments depends on the type of message; there is no upper limit on the amount of arguments sent. Each argument must be separated by a colon and cannot be empty.
\end{itemize}

An example message exchange for joining a channel and sending a message is given as a sequence diagram in figure 4.1.

\begin{figure}[h!]
	\centering
\includegraphics[scale=0.50]{images/int_diag.png}
\center
\begin{center}
\caption{
Diagram of an example message exchange. \textbf{Note:} usernames are in email format. This is shown as u[number] for brevity.}
\end{center}
\end{figure}

This message format was chosen mostly for its simplicity and readability, something which is important when debugging the network components during the implementation stage. By making the protocol format as simple as possible, this also allows the component that interacts with it --- the network controller --- to be designed and implemented in a simpler way than if the protocol was more complex.

As our separation character --- a colon --- may be potentially used in some sent message’s arguments, this character must be escaped to prevent it from being detected as a message component separator when it is in fact part of the argument. This is achieved by doubling the colon (i.e., an emoticon such as ‘:)’ becomes ‘::)’) upon sending the message. When the message is then received and being parsed, adjacent colons should be combined together to get the original argument. As no message component can be blank, this should not cause any problems with the legitimate message separators.

Any binary data that is to be sent as an argument - such as avatar images - should be encoded using Base64 encoding. This is same type of encoding used to attach files to emails and thus is widely used and supported. This type of encoding translates binary data to the ASCII character set, allowing it to easily be sent using our text-based protocol in an efficient, readable manner.

The protocol itself defines no strict limitations in terms of message length, aiming to be as flexible as possible for any protocol evolution in terms of the number of arguments and types of data sent. It is up to the particular client and server implementation to negotiate any limitations, however it is assumed that the server will simply disconnect the client if a message starts to exceed a particular sane size limit (e.g., 1024 characters for sending a chat message).
